🟠 [Medium] OBJ_find_sigid_algs compat macro placed in ssl.h instead of objects.h with the other OBJ_ macros*

Every other OBJ_* -> wolfSSL_OBJ_* compat macro is defined in wolfssl/openssl/objects.h (lines 53-69), co-located with the function it aliases. This PR defines the function wolfSSL_OBJ_find_sigid_algs in objects.h but puts the #define OBJ_find_sigid_algs wolfSSL_OBJ_find_sigid_algs alias in ssl.h (broad OPENSSL_EXTRA block), decoupling the macro from its definition. ssl.h only #includes objects.h under WOLFSSL_QT || OPENSSL_ALL (line 52-55); it works for plain OPENSSL_EXTRA builds only because evp.h happens to include objects.h at its tail. This transitive dependency is fragile: any build path where evp.h is skipped (e.g. WOLFCRYPT_ONLY) would define the macro while leaving wolfSSL_OBJ_find_sigid_algs undeclared, yielding an implicit-declaration error at the call site.

Fix: Move the #define OBJ_find_sigid_algs wolfSSL_OBJ_find_sigid_algs into objects.h next to the function definition and the other OBJ_* aliases, so the macro and its target are always defined together.

🟠 [Medium] WOLFSSL_TLS_ST_OK hardcoded to 16, duplicating internal HANDSHAKE_DONE with no compile-time check

WOLFSSL_TLS_ST_OK (and its aliases TLS_ST_OK/SSL_ST_OK) is hardcoded to 16 to match HANDSHAKE_DONE in the private enum states (wolfssl/internal.h). The value is correct today (HANDSHAKE_DONE is the 17th enumerator, index 16, and wolfSSL_get_state() returns ssl->options.handShakeState), but the coupling is a magic number with no static assertion. The comment even admits 16 today. Because internal.h isn't a public header, a static_assert can't live in the public header, so a silent drift is possible if a state is ever inserted before HANDSHAKE_DONE (the enum comment warns this also breaks session import).

Fix: Add a compile-time check in a .c file that includes internal.h, e.g. wc_static_assert(WOLFSSL_TLS_ST_OK == HANDSHAKE_DONE);, so any future enum drift fails the build instead of silently returning a wrong state constant.

🟠 [Medium] BIO_get_app_data/BIO_set_app_data aliased to BIO_get_data/BIO_set_data (shared storage)

In OpenSSL, BIO_set_data/BIO_get_data access the method-implementation pointer, while BIO_set_app_data/BIO_get_app_data access separate application ex-data. This PR maps BIO_get_app_data/BIO_set_app_data onto the same wolfSSL_BIO_get_data/wolfSSL_BIO_set_data slot that BIO_get_data/BIO_set_data already use (bio.h:163-164). A custom source/sink BIO (the ODBC/FreeTDS transport this PR targets) that stores its connection state via BIO_set_data in its create/ctrl callbacks and also uses BIO_set_app_data for an application pointer will have the two collide - whichever is written last silently overwrites the other.

Fix: Back app_data with a distinct storage slot (e.g. BIO ex_data index) so it does not alias the method data pointer, or document the limitation prominently if the aliasing is acceptable for the intended consumers.

🟠 [Medium] No test coverage for new wolfSSL_OBJ_find_sigid_algs mapping logic

The PR adds a non-trivial mapping function (a switch over ~10 signature-algorithm NIDs producing digest+pkey NID pairs, returning 0 for unsupported), but adds no unit test for it. grep finds no reference to OBJ_find_sigid_algs in tests/, examples/, or testsuite/. Mapping tables are exactly the kind of code where a transposed NID pair would go unnoticed. The verifyNone default got a good targeted test (test_wolfSSL_CTX_verify_none_default); this helper deserves the same.

Fix: Add an api.c test that calls OBJ_find_sigid_algs for a couple of RSA and ECDSA sig NIDs, asserts the returned digest/pkey NIDs and return==1, verifies NULL out-params are tolerated, and asserts an unsupported NID returns 0 without touching the out-params.

🔵 [Low] BIO compat stubs report success/fixed values with silent limitations

wolfSSL_BIO_get_new_index() returns a fixed 1000 for every call, so two distinct app-defined BIO types receive the same index and are indistinguishable if compared. wolfSSL_BIO_meth_set_callback_ctrl() is an always-success no-op that discards the callback and returns 1, which conflicts with the wolfSSL guideline of not shipping always-success stubs (a caller that relies on the callback later being invoked gets no indication it was dropped). The getters correctly return NULL. These mirror OpenSSL's return conventions and are documented in the comments, so this is a low-priority observation rather than a defect.

Fix: If uniqueness is ever needed, hand out a monotonically increasing index instead of a constant. Keep the comment explicit that callback_ctrl is unsupported so callers don't assume the callback fires.

🔵 [Low] wolfSSL_OBJ_find_sigid_algs omits RSA-PSS, EdDSA, and MD5 signature NIDs

The mapping covers SHA1/224/256/384/512 with RSA and ECDSA but returns 0 (unsupported) for other algorithms wolfSSL/OpenSSL know, e.g. NID_rsassaPss (WC_NID_rsassaPss=912), Ed25519/Ed448, and md5WithRSAEncryption (WC_NID_md5WithRSAEncryption=99), all of which are already defined in evp.h. For EdDSA in particular, OpenSSL's OBJ_find_sigid_algs returns 1 with pkey set and digest = undef; returning 0 here diverges and may cause a compat consumer's certificate-algorithm introspection to treat those certs as unknown. This is acceptable as a documented limitation for the current use case but is a divergence from OpenSSL semantics.

Fix: Consider extending the switch (guarded by the relevant feature macros) to cover RSA-PSS and Ed25519/Ed448 to match OpenSSL, or note the intentional scope limitation in the function comment.